Editors have long been used to edit source code for computer programming languages. A language is typically defined by a set of lexical, grammatic, and semantic rules. Code compliant with the language is compiled or interpreted according to the language's rules to produce a translated form which may in turn be code in another language or instruction set, for instance intermediate language code, executable object code, machine instructions, another programming language, and so forth. Editors are generally designed to receive a copy of source code from a source code file or other unit of organizing code, display the source code as editable text in an editing region managed by the editor, and save edits to the source code file. The editor is may be part of an integrated development environment (IDE), which may include compilers, project management features, and other known components.
Code editors generally present code for editing with a one-to-one relationship between the displayed code and the underlying representation stored in a buffer or file. That is, what the code editor displays is a faithful graphic representation of the state of the source code open for editing; the positions of characters, indentations, positions of lines, etc., mirror the content of the code's file or buffer, which is updated in correspondence with editing of the code. The approach of having editors display faithful graphic representations of the underlying code being edited is beneficial, but it has shortcomings.
Many languages have constructs that can make it difficult to understand source code. For example, implicitly typed declarations (e.g., “var”), untyped declarations, and other constructs that can be resolved at compile time, yet such resolution may not be obvious to the user viewing the source code in the typical code editor. There may be many reasons why a user is unfamiliar with the hidden information associated with source code the user is editing. Another user may have originally authored the source code. The user may have written or last reviewed the source code too long ago to recall the meanings of declarations and the like. The editing user may not know the datatypes or classes implicitly referenced in the source code. For instance, the source code being edited might be part of a complex project which may make remembering the meaning of constructs difficult.
In addition to implicit typing information that may be unfamiliar, there may be comments and other previously-authored text in a language not understood by the user. If one user speaks—and codes in—a language not understood by the user currently editing the code, then the code may difficult to read for the non-speaking user. Comments, variable names, etc., may be difficult for the user to understand and work with.
Not only might potentially helpful information be missing, but the editing user is often not accustomed to the formatting of the source code being edited. Required but unfamiliar conventions may make reading the source code difficult.
Two approaches have been used to provide additional information and easier reading to a person editing source code. One approach has been to have editors, perhaps using macros or built-in tools, alter the source code being edited in semantically neutral ways. With this approach, the text being edited is updated in both the editor's view and in the underlying representation (e.g., a buffer storing the code being edited). Whitespace, newline characters, arrangement of block delimiters, and other transforms have been used. While this approach can be helpful, the alteration of the source code has obvious limitations. Furthermore, such alterations tend to be mechanical and may not tailor themselves to the individual user or usage context. Moreover, they can cause difficulties for source code control systems because they manipulate the buffer with spurious changes, making code reviews and history more complex to review.
Another approach has been to make use of user interface enhancements to provide more information to a use. For instance, so-called tooltips have been used to reveal information about source code elements when a user positions a pointer to hover over them. Information panels in IDEs can also provide information about a code construct responsive to selection of the code. However, as only the inventors have observed, this approach provides supplemental information in a way that is inefficient. Because the information is not integrated into the text of the source code being edited, the user may not be able to readily relate the information to the source code displayed in the editor. In addition, the hover-over method can only show information about one target code construct at a time.
Techniques related to in-line code adornment are discussed below.